The present invention is directed to a method and apparatus for handling requests regarding information stored in a file system as part of an operating system, and in particular, to provide a method and apparatus for handling such requests for multiple file systems.
Computer operating systems include several different operational modules. One such module is the file manager. The file manager manages the organization, reading, and writing of data located on data storage media, such as hard disk and removable disk drives. Each storage media has its own associated format for accessing the data on the storage media. Examples of such formats are HFS, MS-DOS FAT, ProDOS, High Sierra, ISO 9660, Unix, etc. Formats encompass both physical disk formats and network server access protocols.
Until recently, computers have been able to access storage media organized under only one format. However, them has been a move to allow computers to access data using multiple formats. At least two systems are currently available which can access storage media using multiple formats.
European Patent Application 0 415 346 to Willman et al. discloses a system adapted for use in a Microsoft.TM. OS/2 operating system for automatically and dynamically mounting a file system which recognizes the media. In the Willman et al. computer system, one or more data storage devices and a plurality of file system drivers are provided including a default file system wherein the file systems are organized in a linked sequence. Each file system driver is able to access file systems of a particular format. The computer system continuously monitors all peripheral devices to detect any change in media in the peripheral storage devices. Whenever media in a data storage device is changed, or the first time the computer system accesses a data storage device, the first file system driver identified in the list of file system drivers is loaded and a volume identifier is read from the media wherein the location of the volume identifier is specified by the loaded file system driver. The volume identifier read from the media is then compared with the identifier associated with the file system driver and the file system driver is mounted if the identifiers match. Otherwise, the next file system driver identified in the linked list of file system drivers is loaded. The process is then repeated until each file system driver in the linked list of file system drivers has been tested or until a match is found. A default file system is mounted if no match is found.
This system lacks flexibility. In particular, the identifier must be in a common known location for all volume formats which can be used by the system. Instead, it is desirable to allow each file system driver to use it's own method of identifying the volume to provide increased flexibility in the volume format.
Another system for accessing multiple file systems is found in the Microsoft.TM. WINDOWS.TM. NT operating system. In this system, messages are sent to a plurality of objects that are maintained by each file system driver, the objects corresponding to the subject of the requests. Thus, if modifications to the processing of particular kinds of messages are necessary, they must be made at each file system driver.
Other file managers are known, such as the System 7 file manager used on Macintosh.TM. brand computers manufactured by Apple Computer, Inc. When a request is received in System 7, the file manager assumes it is a request for access to an HFS (Hierarchical File System) volume used by Apple Macintosh.TM.. If the storage media is not HFS, an error is generated and the file manager passes the request to a piece of code that tries to perform the requested access.
It is desirable to provide a file manager which is a portable version which would be able to run on a variety of processors, and be able to take advantage of the concurrent, asynchronous device managers available in many operating systems. It is also desirable to provide a file manager which provides downward compatibility with the application programmer interface (API) of prior art file managers. By way of explanation, an application programmer interface (API) is defined to provide a specification which allows third parties to communicate with the operating system. For example, in the context of the present invention, an API is defined to provide a specification which allows third parties to communicate with the file manager.
Prior operating systems were built using a monolithic code structure which did not include separate modules for performing specific tasks. Problems developed because it became difficult to make improvements to the system since the entire system had to be rebuilt to make each change. In addition, the entire code ran in privileged mode, causing problems because any component of the systems could interfere with any component causing a error.
The solution to this was to cast as much functionality as possible out of the system into separate services (e.g., the file manager, input/output manager, screen manager, etc.) which ran in less privileged modes, leaving a kernel of code to perform the most privileged functions. Since the kernel was providing an absolute minimum of services, it was rare that it had to be revised. Since each of the other services was independently built, it was easier to revise them. Because most of the system code ran with reduce privileges, the system was more stable. And, because the system was more easily modified, a lot of new features were added because it suddenly became easier to innovate. Thus, modern operating systems typically are designed according to this kernel structure.
Prior APIs, for the monolithic operating systems, rely heavily on global states. It is desirable therefore in such an environment, to develop a new API for the file manager which assumed that all file manager data was in a separate, protected address space, and which allows programmers to migrate towards a secure system in the future.